タグ付け: レガシーシステム改修
レガシーシステム置き換えのパターン
既存のソフトウェアシステムを置き換える必要に直面した組織は、しばしば半ば完成した技術的置き換えのサイクルに陥ります。私たちの経験から、このサイクルを打破するためのパターンシリーズを学びました。それは、レガシーソフトウェアの置き換えによって期待される成果を意図的に認識すること、この置き換えを部分的に分割すること、これらの部分を段階的に提供すること、そして変化が不変の現実であることを認識する組織文化を変えることに基づいています。
モノリスからデータリッチなサービスを抽出する方法
モノリスをより小さなサービスに分割する場合、最も難しい部分は、モノリスのデータベースに存在するデータを実際に分割することです。データリッチなサービスを抽出するには、常にデータの単一書き込みコピーを維持する一連の手順に従うことが役立ちます。手順は、既存のモノリスで論理的な分離を行うことから始まります。サービスの動作を別のモジュールに分割し、次にデータを別のテーブルに分割します。これらの要素は、新しい自律型サービスに個別に移動できます。
メインフレームにおける漸進的な近代化のためのシームの発見
メインフレームシステムは、世界のコンピューティングワークロードの大部分を依然として実行していますが、増大するビジネスニーズをサポートするための新機能を追加することは、しばしば困難です。さらに、それらを強化するのが遅いアーキテクチャ上の課題は、置き換えを困難にもしています。関与するリスクを軽減するために、レガシーシステムの置き換えを段階的に行い、レガシー機能を最新の技術による実装に徐々に置き換えるアプローチを使用する必要があります。この戦略では、メインフレームシステムにシーム(新しいサービスにロジックフローを迂回できるポイント)を導入する必要があります。最近のプロジェクトでは、この長期間稼働しているメインフレームシステムにこれらのシームを導入するためのいくつかのアプローチを調査しました。
モノリスをマイクロサービスに分割する方法
モノリシックシステムが大きくなりすぎて扱えなくなると、多くの企業はそれをマイクロサービスアーキテクチャスタイルに分割することに惹かれます。それは価値のある取り組みですが、容易ではありません。これをうまく行うには、単純なサービスから始める必要がありますが、その後、ビジネスにとって重要で頻繁に変更される垂直方向の機能に基づいたサービスを抽出する必要があります。これらのサービスは最初は大きく、残りのモノリスに依存しないことが望ましいです。移行の各ステップが、全体的なアーキテクチャに対するアトミックな改善を表していることを確認する必要があります。
Dave Farley氏とのエンジニアリングルームでの会話
私の旧同僚であるDave Farleyは、ソフトウェア開発に関するますます人気のあるYouTubeチャンネルを運営しています。彼の経験は私の考え方に大きな影響を与えているため、それは優れた資料であり、私の見解と非常によく合致しています。私たちは、ソフトウェアエンジニアリングの現在の役割に関するさまざまなトピックについて話し合い、特に現在私がサポートしている3つの大規模な執筆プロジェクト(Data Mesh、分散システムのパターン、レガシーシステム置き換えのパターン)に焦点を当てています。
アセットキャプチャ
アセットキャプチャは、Strangler Fig アプリケーションを開発するための戦略です。多くのアプリケーションは、主要な資産セットの管理と考えてください。給与システムは従業員を管理し、取引システムは取引を管理し、リースシステムはリースを管理します。新しいシステムに段階的に切り替えるには、新しいシステムで始める資産のサブセットを特定することから始めることができます。(迅速に開始できるため)単純な資産、または古いシステムでは特に処理が難しいニーズを持つ資産から始めるのが最適です。
歴史はナンセンスではない
歴史は、ほぼナンセンスである。
--ヘンリー・フォード
最近、UML Distilledの読者から不満のメールを受け取りました。怒り狂った読者が、私の時折の知恵の言葉を、読むどころか購入したことを後悔している場合、私の1日は決して良いスタートを切れません。しかし、この読者の不満には特に興味深い点がありました。彼の具体的な不満は、私の「不必要な歴史」に関するものでした。
レガシーシーム
レガシーシステムを扱う際には、シーム(ソースコードを編集せずにシステムの動作を変更できる場所)を特定して作成することが重要です。シームを見つけたら、それを利用して依存関係を解消し、テストを簡素化し、プローブを挿入して可観測性を高め、レガシーシステムの置き換えの一部としてプログラムフローを新しいモジュールにリダイレクトできます。
ナッシュビルプロジェクト
私は最近、私がこれまでに携わったお気に入りのThoughtworksプロジェクトの1つについて時間を費やしました。それは1998年に開始されたプロジェクトで、当時最新のJ2EE技術を使用していました。長年にわたり、それは魅力的な歴史を持っています。EJBから始まり、それらを削除し、バンガロールにオフショアし、シカゴに戻ってきました。多くの人々がプロジェクトに出入りし、プロジェクトの人員数は6人から60人と変化しました。全体として、このプロジェクトには300人年以上の労力が費やされており、約10万行のコードからなります。
ストレンジャーフィグアプリケーション
シンディと私がオーストラリアに行ったとき、クイーンズランド州の海岸にある熱帯雨林で時間を過ごしました。この地域の自然の驚異の1つは、巨大な絞め殺しのイチジクです。それらは木の高い枝に種を落とし、徐々に木を下りて土壌に根を下ろします。何年もの間に、それらは壮大で美しい形に成長しますが、同時に、それらを宿した木を絞め殺して殺します。